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I. 


INTRODUCTION 


A. PREFACE 

Since the early years of procurement, all contracting was done as a paper-based 
activity. With the introduction of mainframe computers, databases were utilized for 
tracking, forecasting, and electronic payments. Next came the desktop/networked PC 
along with word processors and spreadsheets and personal computing was born. This 
was networked into an enterprise system that allowed for nearly seamless transfer from 
requirement to award. The Department of Defense has recently implemented automated 
procurement programs. The Army is fine turning their present Logistics Modernization 
Program (LMP) that is built on SAP-R3 enterprise software. 

Presently, after the contract type has been determined, contract-writing software 
such as Procurement Automated Data & Document Systems (PADDS) and Standard 
Procurement System/ Procurement Desktop-Defense (SPS/PD2) assists with choosing 
and filling in the requirements and FAR clauses as well as delivery and shipping 
information. Although the task has been simplified by use of the software, it is 
nevertheless the same system of contracting that requires careful proofreading to weed 
out ambiguities and contradictions. It is a time consuming process that produces 
inefficiencies and errors. Like a military specification, the contracting officer’s attention 
is constantly directed at ‘how’ contracting is being accomplished. 

For the DoD as well as the rest of the Federal government to manage effectively 
in the twenty-first century, it is the author’s opinion that a system of automated business 
rules are not enough. A more efficient User Interface (UI) and web-based architecture 
must be added to the present system. As in fourth generation programming, software 
assisted contracting must operate from a performance driven perspective. The only 
contracting questions that need to be asked are what do you want and when and where do 
you want it delivered. 
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This research will explore present solutions and suggest solutions that will make 
the contracting practice more efficient, less ambiguous and more able to closely follow 
the laws regarding contracting to sole source, competitive negotiations, sealed bids, 
subcontracting requirements and Small Business. 

B. RESEARCH OBJECTIVE 

The author intends to show the progression from Paper to Paperless Contracting 
and recommend the next step to create a more efficient form of contracting given the 
increased acquisition demands and the retiring workforce with its accompanying loss of 
credentialed personnel. 

C. RESEARCH QUESTIONS 

1. Primary Research Question 

Given the present sate of technology, what steps should the DoD and Army take 
to further improve procurement software and User Interface (UI)? 

2. Secondary Research Questions 

• What have other agencies done to streamline and automate procurement? 

• What type of enterprise architecture is available to explore and exploit? 

• What are the pitfalls associated with the present system? 

• What methods can be used to further increase efficiencies and 
effectiveness? 

D. SCOPE AND ORGANIZATION 

The author will account for how the DoD, and specifically, the Army makes their 
purchases. 

Next, the possible opportunities to bring procurement into an online paperless 
ordering activity are researched. 

Finally, specific enhancements for implementation are discussed. 


2 



E. METHODOLOGY 


This research is theoretical and exploratory. The data for this project will be 
primarily web-based records from the DoD and the Army. These will be combined with 
background research of enterprise architecture and business rules research. 

F. BENEFITS OF RESEARCH 

This study is intended to offer insight into the future for the direction of DoD 
enterprise procurement systems. 
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II. LITERATURE REVIEW AND BACKGROUND 


A. INTRODUCTION 

This project begins by examining the existing system of contracting. Next, 
commercially available software solutions including enterprise systems will be examined. 
Finally, the governments contracting needs with its incoming workforce and look for a 
system of Paperless Contracting that will embrace present day enterprise architecture 
solutions will be incorporated. 

The Standard Procurement System (SPS) under the Clinger-Cohen act provides 
for large scale contracting improvement by the government. A hearing of the House of 
Representatives (February 7, 2002) explored various government failures in acquisition 
modernization as seen below. 

The standard procurement system was meant to address both problems. 
Standardization of contract and purchasing processes should bring greater 
transparency and data commonality to DoD’s tangled web of financial 
systems. Selection of a commercial, off-the shelf product should have 
brought efficiency and discipline to the data system development. Today 
we ask whether SPS, the 7-year-old, $359 mi llion Department of Defense 
effort to modernize, streamline, and unify Pentagon contracting, has 
become an expensive part of the problem or a partial solution to the 
Pentagon’s chronic financial management woes. (United States, 2003). 

Fraud and waste are continued themes throughout the report. SPS is one of many 
attempts that have failed to bring the acquisition system up to the standard of private 
industry. 

B. ANALYSIS OF EXISTING SYSTEMS 

The existing acquisition system is leaving talent stretched too thin. Less 

experienced people are handling complex tasks and productivity is lost while the new 

hires are acclimatizing to the workforce. Support for this statement can be found in many 

places. In “Many contract officers quitting,” Castelli addresses the issues concerning 

contracting personnel retiring and leaving the acquisition force (Castelli, 2008). 
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According to a report entitled “Contracting workforce needs more training,” Newell 
emphasizes the need for more training. A survey by Office of Management and Budget’s 
Office of Federal Procurement Policy and the Federal Acquisition Institute indicated that 
they “advocated training in negotiation skills, strategic planning and the effective 
resolution of contract disputes” (Newell, 2007). Denett, in “The 2007 Federal 
Contracting Workforce Competencies Survey,” asks the question it is possible to train an 
incoming workforce while both technical and general competencies are being lost 
(Denett, 2007)? Our present software solutions are a piecemeal effort at best. Indian 
Head Division of the Naval Sea Systems Command stresses the need for contractors to be 
registered with Central Contractor Registration (CCR) and Wide Area Work Flow 
(WAWF) (Kennedy, 2008). An EBay type solution that has gained favor is the reverse 
auction. FreeMarkets on the GSA schedule provides a bidding environment whereby 
live, online bidding transpires for items that do not require negotiation (Kutner, 2000). 
The Business Management Modernization Program (BMMP) will impose strict standards 
on all business systems and require them to be compliant with DoD’s Business Enterprise 
Architecture (BEA). The BEA was developed to ensure financial compliancy, data 
accuracy, streamlined processes, and improved decision-making across the Department 
(Sylvester, 2004). Procurement Automated Data & Document Systems (PADDS) is the 
Army’s contracting system for acquiring major weapon systems and their supporting 
logistical spare parts (O’Boyle, 2008). It has become web based and incorporates an 
online training module. The rules based environment of Army’s Eogistics Modernization 
Program (EMP) provides the latest attempt by the Army to provide enterprise software 
for contracting. Computer Sciences Corporation has customized SAP-R3 for the 
government (Walker, 2006). Port Monmouth is part of the initial rollout. CECOM at 
Port Monmouth, with its eleven billion plus annual contracting receipts, is the test bed for 
EMP enterprise system. The last of the software to be introduced is The Army Single 
Pace to Industry. This program coexists in the Army with EMP. Pigure I illustrates its 
position in the acquisition schematic: 
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Figure 1. Flow Chart - Army Single Face to Industry (ASFI) (From: ASFI, 2006) 


The process of posting solicitation data/documents to the ASFI shall be 
accomplished utilizing one (and only one) of the applications/processes 
listed above. They are via the Standard Procurement System (SPS, 2008) 
using Extensible Markup Language (XML) files and the Defense 
Automatic Addressing System Center (DAASC), the Interactive Business 
Opportunities Page (IBOP), the Army Materiel Command Procurement 
Automated Data and Document System (PADDS), and via Manual Entry 
(approval required). Using multiple processes will cause an error in the 
posting of solicitation data/documents to the ASLI and other applications 
such as Lederal Business Opportunities (LedBizOpps) (ASLI 2006). 


C. COMMERCIALLY AVAILABLE SOFTWARE 

Adobe Acrobat software was explored as a possible solution to paperless 
contracting by Freeman and Sherman in a recent thesis. Their system would allow 
documents to be scanned into a database and linked by way of a manually entered 
indexing system. The system relies on an accurate, manual entry index (Freeman, 
Sherman, 2007). 
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SAP-R3 is a highly customizable enterprise software solution that includes 
Customer Service (CS), Financial Management (FM), and Supply Chain Planning (SCP). 
SAP is a propriety system that uses a database that links to applications. All transactions 
are within the confines of the software with the PC serving as the terminal. Approvals 
and signatures are electronic and digitally signed thus eliminating the need for paper 
(LMP, 2002). 

D. COMPLETING THE SYSTEM 

In discussing the next steps in DoD business systems innovation, the GAO has 

said, 

The DoD Business Systems Modernization agrees that additional work is 
required and states that under its incremental approach to developing the 
architecture and transition plan, and under its tiered accountability 
structure for reviewing and approving business system investments, 
improvements will occur in its architecture, transition plan, budgetary 
disclosure, and investment management and oversight. If these 
improvements do not occur, DoD’s business systems modernization will 
continue to be a high-risk program (GAO-06-219, 2005). 

One way to reduce this risk is for applications to become more interoperable. 
This can happen when a universal set of rules are applied as metadata. This can only 
happen in the web utilizing The World Wide Web Consortium guidelines (W3C, 2008). 

A SAP white paper discusses how systems evolve which are not interoperable. 
“Companies embark on too many individual IT and transformation projects without 
considering how they overlap or whether they are all strategically necessary and, as a 
result, use up too many resources. Functional organizations tend to retain their older 
processes, thereby maintaining workload for themselves, while they develop systems 
requirements based on current processes. With limited senior governance and no 
overarching authority, some implementations are left to be managed as individual 
projects, with no attempt to connect them, learn from them, or in any way treat them as 
the fundamental machinery of change that they actually were” (Tomb, Dickson, 2006). 
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To improve interoperability, it is the author’s opinion that an Open software 
solution must be developed. Rather than rely on a single commercial enterprise system 
such as SAP or any particular proprietary system, it is necessary to go in the opposite 
direction. Rather than being bound to a closed system, an open system that can transfer 
data and metadata between applications is needed. Proprietary software has no future in 
the next generation of web applications. 

As will be detailed in the next chapter, the current DoD paperless system is a 
collection of proprietary systems that is not actually paperless, but maintains what will be 
defined in the next chapter as a ‘paper-based mentality’. Recent attempts to modernize 
the contracting process have helped, but they are nevertheless a piecemeal attempt. 
Commercial software solutions are available which are web-based. The author will argue 
that the persistence of a paper-based mentality is because of a utility users find in old 
paper-based systems, which the current pseudo-paperless systems lack. The author will 
also postulate that whatever solutions are sought, they must adhere to web standards as 
imposed by The World Wide Web Consortium to insure interoperability between 
government and contractors databases and business software. By building on those 
standards, in the fifth chapter, a vision of a contracting system based on these standards, 
which synthesizes the human utility of paper-based systems with the cost-saving potential 
of truly paperless systems will be presented. 
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III. ANALYSIS OF EXISTING SYSTEMS 


A. INTRODUCTION 

The DoD, including the Army, works with many diverse software systems during 
its cradle to grave procurement process. The interaction between the programs is less 
than perfect. Twelve software systems in use by the Army and at CECOM are evaluated. 
In this evaluation, it will be shown that many actions are performed with a ‘paper and 
paper-based’ mentality. 

A ‘paper-based mentality’, in the author’s opinion, happens when electronic 
documents look and are treated like the paper documents they replaced. In the author’s 
experience, entire electronic contract folders have been reproduced in paper and given to 
Program Managers, legal and used for negotiations with contractors. Many documents 
begin as paper only to be scanned into the ‘paperless’ system. Contrast this to a 
‘paperless’ mentality meaning no paper, with data storage, retrieval and display based on 
computer technology and aesthetics, rather than mimicking paper. Application input 
forms are different from reports and queries. Only required information is input or 
displayed. 

B. PROGRAM MANAGEMENT 

The evaluation of this project will be confined to software and hardware systems 
used throughout the procurement development, from cradle to grave. The procurement 
process begins with a requirement emanating from a Program Management Command. 
Contracting is brought into the process early to facilitate the acquisition. 

As seen in Figure 2, there are division points and phases. Documents are 
generated that last throughout the life of the contract. These documents are passed to all 
who touch the project. As to be shown, due to the proprietary nature of the software used 
by the DoD and contractors, many of the documents including specifications, drawings 
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and contracting vehicles are transported by paper or a paper-based mentality. Since the 
paperless mandate, electronic paper exists in the form of Portable Document File (PDF) 
scans and email. 

DEFENSE ACQUISITION DECISION POINTS AND PHASES 

(DoDI 5000.2) 


USER NEEDS & 

TECHNOLOGY OPPORTUNITIES 



Process entry at Milestones A, B, or C 
Entrance criteria met before entering phase 
Evolutionary acquisition or single step to full capability 


i 


Program Tk. a 

L Initiation A 


CONCEPT 

TECHNOLOGY 

SYSTEM DEVELOPMENT 

PRODUCTION & 

OPERATIONS 

REFINEMENT 

DEVELOPMENT 

& DEMONSTRATION 

DEPLOYMENT 

& SUPPORT 



DESIGN 

FRP 


^ CONCEPT 
/ DECISION 


<()> READINESS 

^ DECISION 




^ REVIEW 

REVIEW 



Pre-Systems Acquisition 


Systems Acquisition 


Sustainment 


Figure 2. Defense Acquisition Decision Points and Phrases (From: DAU Program 

Managers Tool Kit, 2008) 

The Integrated Framework Chart (IFC) is a pictorial road map of key activities in 
the systems acquisition process including the Joint Capabilities Integration and 
Development System (JCIDS); Defense Acquisition; and Planning, Programming, 
Budgeting, and Execution (PPBE) (Refer to Eigure 3). There is in integrated system for 
handling information or data. There is no transparency in the data or metadata to allow 
various systems to interpret and integrate information and data from other systems 
without a high degree of risk from corruption when translating data into another medium 
(DAU Program Managers Tool Kit, 2008). 
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Figure 3. The Integrated Defense Acquisition, Technology and Logistics Life Cycle 
Management Framework Chart - Interactive (From: https://akss.dau.mil/ifc/) 
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C. STANDARD PROCUREMENT SYSTEM (SPS) 

The Standard Procurement System (SPS) with over 20,000 users at more than 800 
sites was designed to standardize and automate the procurement process within all 
branches of the DoD (SPS, 2008). PD Squared is the Procurement Defense Desktop 
(PD2) that allows for input into the system. Additional linkages incorporate tracking of 
financial data throughout the lifecycle of the procurement process. SPS is one of two 
solicitation entry systems shown in Figure 1. 

SPS includes PRWeb (funding application) and PD2 (desktop application) to 
initiate and track an award through closeout. Funding is entered into PRWeb and 
forwarded to PD2 where the contracting officer attaches it electronically to the contract. 
PD2 generates solicitations and awards, modifies and closes contracts. Paper documents 
are scanned and stored in paper image (PDF) format. External links facilitate payment 
through Wide Area Work Flow (Wide Area Workflow Application Information, 2008). 

D. PROCUREMENT AUTOMATED DATA AND DOCUMENT SYSTEM 

(PADDS) 

The Procurement Automated Data and Document System (PADDS) provides the 
Army Material Command with a standardized system for preparation, recording and 
processing contracting documents (O’Boyle, 2008). The PADDS system is used by more 
than 2,000 contract specialists. The most recent development was the transition to 
becoming web based. Seven databases were consolidated into one usable system. 
Programming and security patches can now be administered from one location. 

SPS and PADDS provide the first input system as shown in Figure 1. Paper 
documents provide the initial data input into both systems. The funding document is 
signed with a wet signature. The requirements are provided as signed printed documents. 

To post the solicitation, four more systems must be traversed. Although the 
systems talk to each other, not all information or data is shared. The databases are 
proprietary to an individual system. Therefore, data that has made the trip, passing 
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through each software package, will have been translated into data with proprietary 
characteristic to that system. Character strings can be truncated and formatting will lose 
consistency or be lost entirely. 

The loss of data integrity caused by these transfers is precisely the sort of thing 
automation was supposed to ameliorate, by avoiding the transcription errors that used to 
be caused by multiple data entry. The fact that these sorts of errors still occur even in the 
automated systems is an example of what the author calls a paper-based mentality. 

E. INTERACTIVE BUSINESS OPPORTUNITIES PAGE (IBOP) 

The Interactive Business Opportunities Page (IBOP) is a gateway where the 
vendors meet the government to transact business (IBOP, 2008). Here they will find 
synopses, solicitations and drawings. Access to the to the site controlled by the user’s 
role. By using the IBOP, acquisition time has been reduced by an average of seven days. 
Vendors can see and respond to requests for proposal but cannot see each other’s 
proposals or other correspondence (IBOP, 2008). 

Except for manual data input, the IBOP is paperless and has a ‘paperless 
mentality’. It is operated through a web portal and has no forms associated with it. 

F. DEFENSE AUTOMATIC ADDRESSING SYSTEM CENTER (DAASC) 

Defense Automatic Addressing System Center (DAASC) interjects several 
services into the procurement process as it continues to Federal Business Opportunities 
web site for posting (Refer to Appendix A). These include an inquiry system of routing 
codes and identifiers including an ability to query the database. DAASC can track and 
report response times as material flows through the logistics pipeline. There are twelve 
nodes for measurement (DAASC, 2008). 

DAASC is a paperless system that functions as a hub for several activities. It 
serves as a middle ware interface allowing many different enterprise systems and 
applications to transfer data and information. 
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G. ARMY SINGLE FACE TO INDUSTRY (ASFI) 


The Army Single Face to Industry (ASFI) is yet another layer added to the 
automated and updated procurement process (See Figure 1). Solicitations are added to 
the ASFI site using parameters found in 3.0 ASFI EDIT CRITERIA of the user’s guide 
(Refer to Appendix B). While traversing the website, message boxes alert one to the 
various systems that will be encountered while searching for documents or adding 
information (see Eigure 4) (ASEI, 2006). 


Mtcfosoft Inlefnel Exploiei 


PLEASE NOTE. 

You are now leaving Ihe ASR web site! 

If you expcfince problems viewing fhe foiowng page|$t 
please conlaci fhe conliaci specialist noled on this page 
Thanksi 

i| 



Eigure 4. MS Note - Army Single Eace to Industry (ASEI) (Erom: ASEI, 2006) 

Pre-solicitation, Solicitation and Award entries to EBO can be manually uploaded 
through this web portal. Databases impose rules for data entry. As seen in Appendix B, 
each data item has a format and attributes assigned to it such as Close Date and ESC. 
The NAICS must match a validation list stored in the database. Dates are entered in 
many formats: i.e., MM/DD/YY, MM/DD/YYYY, YYYYMMDDD, and DDMMYYYY. 
Metadata is data about data. Transparency between databases implies a standardization 
of metadata (Jones, 1990). If this data is shared with other databases, metadata must be 
provided and understood by the sharing systems to prevent data corruption. 

H. FEDERAL BUSINESS OPPORTUNITIES (EBO) 

Federal Business Opportunities (EBO) is the last system in the Figure 1. EBO is 
the portal where the author, as a contracting officer for construction, write a synopsis. 
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upload the solicitation that was produced in PD2 and post drawings and specifications. 
This effort does not share information between FBO and PD2. They are independent 
operations. The complete process as shown in Figure 1 illustrates the mix-and-match 
approach DoD has taken toward procurement software solutions (FBO, 2008). They 
have continued to modernize and update by going web based with the programs. 
However, they remain fragmented systems with a lack of true connectivity, and hence are 
not truly paperless. 

I. WHOLESALE LOGISTICS MODERNIZATION PROGRAM (WLMP) 

The Army Working Capital Fund (AWCF) business practices had been the same 
for the past thirty years. The Wholesale Logistics Modernization Program (WLMP) was 
the Army’s replacement system for the Commodity Command Standard System (CCSS) 
used to store logistics data pertinent to the operations of the Federal supply system. 
WLMP was intended to overcome the weaknesses sited in the Army’s FY 2000 financial 
statements (Refer to Appendix C) (WLMP, 2001). In addition. United States Standard 
General Ledger (USSGL) was interfaced with WLMP to allow for tighter accountably 
(USSGL, 2008). 

The WLMP modernization program has a single point of entry. The data is 
manually entered and therefore the input paper-based. Since the data is contained within 
one system, all of the applications within the system will share compatibility. However, 
there is no indication this database can be shared reliably with external systems. In 
operation, it ‘paperless’ in that information is entered to an electronic form. However, 
custom reports and queries are summoned from the database and printed giving it a 
‘paper-based mentality.’ 

J. LOGISTICS MODERNIZATION PROGRAM (LMP) 

The Logistics Modernization Program (LMP) is the most recent of the enterprise 
systems for the Army. The Fort Monmouth’s CECOM Acquisition Center, in 2003, 
became the test center for the initial rollout. Computer Sciences Corporation customized 
SAP-R3 to take over several previous systems that were not interfaced (LMP, 2002). 
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LMP represents a clash in disciplines. It is the Army’s attempt at implementing a 
one-size-fits-all paperless contracting system. Since its inauguration, this author has 
observed new paper contract folders being assembled with most new requirements. 
Based on the author’s observations, this is another example of a paperless system with a 
paper-based mentality. Before LMP, contract specialists carried the contract folder to the 
contracting officer for review. Since LMP, the contract specialist prints out on request 
potions of the contract for review. After review, the paper is discarded. 

K. PROJECT CONTRACT FOLDER (PCF) 

Included in the rollout was an electronic filing cabinet system that allows for 
approvals and digital signatures. Since then, the Project Contract Folder (PCF), system 
has been distributed to more than 350 locations worldwide (PCF, 2008). 

PCF is de facto paper-based mentality in that it mimics the paper folder and its 
documents. It is used to rout documents for approval and electronic signature as well as 
storage. There is enhanced security in that permissions are assigned for read only, edit 
and signing capabilities. The author has seen many documents printed, shared and 
discarded by some while others are toting their government notebook computers with 
them and sharing documents electronically. Because of these observations, the author 
claims that PCF is helping in the transition to the paperless mentality by giving the option 
of printing when hard copy is more appropriate for review and evaluation. 

Rollouts are always troublesome at best. The LMP system included training that 
was divided into SAP functions such as Customer Service (CS), Financial Management 
(FM), Supply Chain Planning (SCP) and Product Lifecycle Management (PLM) (LMP, 
2002 ). 

CECOM utilizes a variety of systems. Contracting done for Base Operations uses 
SPS/PD2 and FedBizOpps to accomplish its mission. The rest of CECOM uses the 
IBOP, EMP, PADDS, PCE, ASEI, and EBO. They are in a continual state up upgrading 
with different agencies having responsibility for each system. 
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L. DOD ARCHITECTURE FRAMEWORK (DODAF) 

The DoD Architecture Framework (DODAF) is the document that addresses 
interoperability issues among the various systems in use by the DoD within their Net- 
Centric Environment. The DoD Integrated Architecture Panel defined architecture as: 

The structure of components, their relationships, and the principles and guidelines 
governing their design and evolution over time. (DoD Integrated Architecture Panel, 
1995, based on IEEE STD 6I0.I) 

Specification templates are sufficient for in house services. However, when 
interfacing with outside services, a detailed, machine-interpretable specification is 
necessary (Refer to Appendix D). 

Shown in Eigure 5 are the relationships between three views within DODAE 
architecture. The views expressed have been designed to be in agreement within an 
express architectural system. However, collaboration does not take place between 
external systems that will be sharing data and information. The DoD has a piecemeal 
effort of proprietary systems that are attempting to share information and data on a need 
to know basis (DODAE, 2007). 
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Source: DOD Archltecturo Framework Version 1.0, Volume 1. 


Figure 5. Interdependent DODAF Views of an Architecture (From: DODAF, 2007). 


M. SOLUTIONS FOR ENTERPRISE-WIDE PROCUREMENT (SEWP) 

Solutions for Enterprise-Wide Procurement (SEWP) is NASA’s attempt at a GSA 
ordering device. Originally entitled Scientific and Engineering Workstation 
Procurement, SEWP is a Government-Wide Acquisition Contract (GWAC) vehicle, 
consisting of 38 pre-competed Contract Holders consisting of 48 Indefinite Delivery 
Indefinite Quantity (IDIQ) contracts. SEWP was designed to comply with the Pair 
Opportunity as required by Pederal Acquisition Regulations (PAR) Part 16.505(b) (PAR, 
2008). 
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Email has been around sinee 1971. The Faesimile maehine was introdueed at the 
turn of the eentury. SEWP’s method for ordering depends on one of these two methods 
(Refer to Appendix E). Inquiries are handled via telephone Helpline and email. 

At the SEWP website, one will find seareh tools as well as information that will 
assist the eustomer in determining how best to fulfill their requirements needs (SEWP, 
2008). 

SEWP’s fax manual entry, in the author’s opinion, is a throwbaek before online 
ordering. The eoneept is diehotomous in that produet searehes and downloading order 
forms are performed online. This is an example of what the author refers to as a low-teeh 
paper-based solution that enables data entry personnel at SEWP to adapt orders to meet 
ehanging eonditions in the supply ehain that would otherwise eall for teeh support 
intervention. In this ease a ‘paper-based’ mentality may have utility, in that orders ean be 
filled utilizing telephone or mail serviee whieh may have its plaee in the time of a 
national emergeney when IT infrastrueture may not be dependable. However, in the 
author’s judgment, sueh redundaney is best maintained at the level of baekup proeessing 
- while primary transaetions should be eondueted in a paperless fashion. 

N. SUMMARY 

Program Management initiates their requirement. The Army Single Faee to 
Industry (ASFI) is eomprised of Standard Proeurement System (SPS) or Proeurement 
Automated Data and Doeument System (PADDS) and leads into the Interaetive Business 
Opportunities Page (IBOP). The aetion also passes form SPS and PADDS to Defense 
Automatie Addressing System Center (DAASC) and through ASFI ending up as a 
solieitation on FedBizOpps. 

The Wholesale Eogisties Modernization Program (WEMP) was an effort to better 
manage AWCF. The Eogisties Modernization Program (EMP) was the Army’s latest 
attempt at modernization and ineludes eleetronie Projeet Contraet Folder (PCF). 

The DoD Arehiteeture Framework (DODAF) shows what has to be taken into 
eonsideration to get various systems to share data and information. 
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Solutions for Enterprise-Wide Procurement (SEWP) was NASA’s attempt at a 
GW AC contracting device. However, it relies on email and facsimile to translate 
requirements into awards. 

With the exception of DAASC, the systems presented fail at being truly paperless 
due in part to paper-based manual data input and the constant printing of documents 
needed for collaboration, and legal review. Paper can be easily handled and there are no 
new skills to be learned. The technology necessary for procurement consists of a pen and 
a ream of paper. Add to this the sophistication of the last century with its preprinted 
forms, typewriters, photocopiers and the facsimile. Even when technology supports 
innovation, humane nature is resistant to change. 

In conclusion, paper and the paper-based mentality have followed the DoD into 
the twenty-first century. 
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IV. COMMERCIALLY AVAILABLE SOLTWARE 


A. INTRODUCTION 

Commercial software consists of large integrated enterprise systems such as SAP 
and large enterprise system built around a database such as Oracle. 

Singular applications such as ACART represent a different kind of software. 
These applications assist and add functionality to other applications and databases within 
the business structure. 

Architecture is the framework the applications run on. As an analogy, if the 
hardware part of a network were the paved roads then the architecture would be the signs 
and traffic lights. 

The author have researched two approaches coming from opposite perspectives. 
Service Oriented Architecture (SOA) is complex ‘top down’ architecture whereas; Web 
Oriented Architecture (WOA) is small scale, grass roots, that is an interface-level 
architectural style (Smith, 2008). 

B. SAP 

The SAP preference of relying on their system and personnel is evident in the 
following excerpt: 

Implementation programs with the set goal of “replacing systems” - 
without mentioning process improvement - are doomed to failure. Best 
practice indicates that a successful implementation can in fact force an 
organization to reevaluate its business practices and processes, focus on 
clearly defined goals and objectives, create a higher understanding of the 
need for data accuracy, emphasize time-phased material planning, and 
enable a more effective datasharing environment. However, such high- 
level benefits require a new approach to project implementation, one that 
applies the lessons of the past to reinvent the systems of the future (SAP, 

2008). 
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Enterprise resource planning (ERP) systems designed by SAP may be purchased 
as a complete system needing very little customizing to integrate with a business’s 
existing system. Another approach is to install the system and import preexisting data 
into the SAP database. This requires imported data to be cleansed and justified to the 
appropriate requirements for SAP. Although this is a separate operation, it is only done 
once. All subsequent data will be entered in native mode to SAP. Adapting input to an 
existing system allows SAP to utilize the modules of an old system but requires 
customized programming to do so. The benefit to this approach is that existing software 
is left intact and IT is already fa mi liar with it. The downside is the preexisting data and 
concepts will not be an exact “fit” with SAP and cause debugging problems that cannot 
be readily solved. 

SAP is a highly prioritized system. It requires custom patches and programming 
to hand off data and information to other systems. When implementing a new system, 
SAP suggests evaluating Best Practices as described below: 

Best practice indicates that a successful implementation can in fact force 
an organization to reevaluate its business practices and processes, focus on 
clearly defined goals and objectives, create a higher understanding of the 
need for data accuracy, emphasize time-phased material planning, and 
enable a more effective data sharing environment. However, such high- 
level benefits require a new approach to project implementation, one that 
applies the lessons of the past to reinvent the systems of the future (SAP, 

2008 ). 

SAP moves away from the traditional stovepipe environment instead favoring a 
holistic, closed-loop framework that incorporates, as an integrated process, marketing and 
sales. Integrated sales and marketing (ISM) within the SAP system creates a 
homogeneous relationship between sub systems. This facilitates one data source being 
used for several operations. 
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An ISM approach combines existing technology such as enterprise 
resource planning and customer relationship management with capabilities 
such as dynamic sales and operations planning, global data 
synchronization, point-of-sale-based advanced analytics, integrated trade 
promotions management, multi-tiered collaboration and shared scorecards, 
brand management, retail execution, and category management (SAP, 

2008). 

The ISM approach allows for more integrated decision-making. Total lifecycle 
with its critical path and milestones are included into one integrated system for queries 
and reports as illustrated in Figure 6. 
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Figure 6. The ISM approach (From: SAP, 2008) 

DoD has an equally complex framework as seen in Figure 3. Whereas, The ISM 
approach in Figure 6 in integrated and paperless. The Integrated Defense Acquisition, 
Technology and Logistics Life Cycle Management Framework Chart makes its 
connection with many proprietary applications and manual data input. Figure 6 is a 
template where DoD titles could replace the titles shown. 

Metrics are an important part of any business. SAP provides analytics to qualify 
and quantify an operation. 
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• Better ability to discover and leverage new brand and product portfolio 
insights at the shelf 

• Faster, more effective product introductions (and phaseouts) 

• Increased consumer satisfaction and brand loyalty 

• Enhanced employee satisfaction, thanks to fewer interfaces and software 
to be learned 

• Improved sales channel satisfaction and retention of top sales and service 
people 

• Speedier channel partner ramp-up time 

• Improved alignment and consistent execution of corporate strategy 

• Increased fill rates 

• Enhanced brand asset utilization 

• Improved financial performance, such as increased invoice accuracy and 

decreased cash-to-cash cycle (SAP, 2008). 

Although SAP systems are designed to operate most efficiently within its own 
structure, supply chain and back office information must be importable. Managers need 
the capability of performing what if queries drawing on both internal and external 
databases. SAP is a robust system that can stand-alone and operate on its one integrated 
database while it allows for external connections to be integrated into its analytical 
processes. 

In an effort to compete more effectively with Oracle, SAP is developing a Service 
Oriented Architecture (SOA) that allows its applications to interact as web applications 
within their system. 

C. ORACLE 

Recently, PeopleSoft was acquired by Oracle. The following was taken from an 
Oracle Applications Strategy Briefing (Video) given by Charles Phillips as he discusses 
Oracle Eusion Middleware (OEM) development and integration. 

PeopleSoft, ID Edwards and Retek are combining the best of their 

applications and linking them to the Oracle database as well as each other 

through OEM. Throughout the seminar, OEM was compared to SAP Net 

Weaver. Both are examples of SOA. 
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Information Age Applications are Information, Standards and Industry 
driven. 

SAP is the leader due to its integrated applications. Oracle is moving to 
close the gap with its development of OFM. The Oracle database can be 
linked to applications through sophisticated middleware. Oracle will then 
be able to purchase applications and integrate then into the Fusion 
environment. Applications are developed independently. The best in 
class are purchased and added in to the system. By developing this way, 

Oracle can meet the present needs of the customer while continuing to 
develop for future iterations. In addition, software must remain 
upgradeable until such time the customer is able to transition into a 
different application. Oracle’s focus is a mergence or past, present and 
future applications facilitated by OFM. 

Software of the future will meet the customer’s needs rather than causing 
the customer to conform to the application. Total Ownership Experience 
and Security is the hallmark of the future. 

With a close customer relationship, 400 hundred advisor boards drive 
product direction. At Oracle, they “Try to look at needs out in the 
future.. .skating to where the puck will be.” 

Customer Relationship Management (CRM) technology collapsed because 
it did not help sales people. Therefore, they did not use it. They were 
receiving data while needing information. 

Build to the ‘process’ of the customer’s needs and provide long-term value 
with supportable and upgradable applications that will interface through 
OFM to the Oracle database and external environment (SAP, 2008). 

At one time, Oracle was thought of as a database company while PeopleSoft 
marketed applications. SAP installed customized, proprietary enterprise systems 
consisting of its own applications coupled to its database. Oracle bought PeopleSoft to 
achieve parity with SAP (Oracle and PeopleSoft, 2008). 

Oracle is known to buy a company to acquire its applications rather than 
developing in house. Oracle Fusion Middleware (OFM) became a necessity to create 
interoperability within the company’s applications (OFM, 2008). 


27 



D. ACART 


ACART is an ad hoc tool that allows the users to extract information from 
dissimilar systems and make comparisons (ACART, 2008). 
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Figure 7. Sort and map enterprise requirements for targeted reporting (From: ACART, 

2008) 
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ACART uses a paper-based mentality with a paperless solution. The query tool 
allows one to choose information from a multitude of systems to be evaluated and 
determine the rules of evaluation just as though the documents had been gathered and 
categorized on a desk. Information is collected and reports are written and published. 

E. ARCHITECTURE 

Commercial enterprise systems employing Service Oriented Architecture (SOA) 
have not been entirely successful due complexities and cost found in development 
(Hinchcliffe, 2008). 

• SOAs tend to have a small and well-defined set of endpoints through 
which many types of data and data instances can pass. 

• Traditional SOA builds a messaging layer above HTTP using SOAP and 
providing unique and sometimes prohibitive constraints to the Web 
developer 

• SOA was designed from the top-down by vendors to be tool friendly 

• SOA uses WS-Security and other sophisticated standards for security 

• SOA must contend with the vagaries of XML Schemas for service 
contracts 

• Traditional SOA is fairly cumbersome to consume in the browser 

• Traditional SOA is facing a crises of identity at this point, particularly 
given fairly lackluster results (Hinchcliffe, 2008) 
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SOA Reshaped by the Web 2.0 Era: 
Granular, Radically Distributed, Web- 
Oriented, Open, Highly Consumable 
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Figure 8. Service Oriented Architecture (From: Hinchcliffe, 2008) 


F. SUMMARY 

Commercial enterprise solutions consisting of large-scale application and its 
database present one side of the solution. The rest of the problem is solved by employing 
an ad hoc collection of applications that perform a specific purpose. Without a common 
interface or standardized data, it can be difficult making some of these applications work. 
Proprietary software shuts out other application while creating a barrier for itself. 
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V. COMPLETING THE SYSTEM 


A. INTRODUCTION 

The DoD has made the transition to a kind of automated, paperless contracting. 
However, much of it remains based in what the author calls a ‘paper based mentality’. 
To be fully functional, it must become people friendly. Just as in ergonomic issues 
concerning where and how people work physically, the ergonomics of business 
functionality must be addressed. The DoD needs to make the paperless environment 
look, feel and operate like paper in the ‘minds’ of contracting personnel. Without this, 
the DoD will continue to need filing cabinets, printers and photocopiers. Redundant 
systems of paperless and paper-based have evolved requiring additional maintenance 
(Sellen, 2008). 

B. WEB-BASED MENTALITY 

What the author refers to as a ‘Web-based mentality’ is a construct that 
synthesizes the persistent human utility of Paper-Based systems and paper-based 
mentalities with the computational and cost efficiency of Paperless systems. There are 
processes that are inherent with humans such as visualization and manual manipulation. 
Humans desire communication with one another. Since the dawn of civilization, until 
recently, communication media was seen and handled. It could be understood by what it 
looked like and how it was seen to function. 

In the middle twentieth century, that concept began to change. Mainframe 
computers stored data. Manual data input is an impersonal process. As the paperless 
revolution continued, more of the process was automated and performed by software 
applications. 
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As the process begins, a new account is entered into the system. It is uploaded by 
manual data input. The process involves the customer filling in a form, which is then 
input by a clerk. From this point forward, the account is paperless until the mail comes 
and the customer opens the envelope and reads the bill. 

Today, the world has progressed to electronic transfers of funds. Humans touch 
very little of the process. 

The Web-based process puts a ‘human face’ on the paperless environment. The 
World Wide Web has become the paper of the twenty-first century. People of all ages 
are as comfortable interacting with web applications as they are reading a magazine or 
filling in the form for a car loan. 

Procurement has followed the same route. In the beginning, all acquisitions were 
done on paper and handled by people. Then in the mid twentieth century, mainframe 
computers were employed. This was followed by networked personal computers. 

The contracting process is complex and requires the continual review of the 
contents of the document folder. Since this folder has become electronically stored, it 
must be viewed on a monitor. 

This process has not been accepted by many in contracting. In the author’s 
experience, many contracts at CECOM have complete paper-based contract folders. 
They exist to facilitate contract negotiations and document maintenance. PCF was 
intended to bring closure to paper-based contracting. Nevertheless, reams of paper are 
being printed every day in a paperless environment. This is followed by shredding, since 
being paperless, there is no need for filing cabinets. 

In the past year, notebook computers have been issued to some as well as dual or 
wide-screen monitors and docking stations in an attempt to become truly paperless. The 
author carries his notebook computer to meetings only to find that he is the only person 
with a computer. He still needs a note pad because typing is disrupting to others and the 
battery only lasts two hours. 
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Acquisition enterprise applications must be made to be more desirable to use. 
While people are comfortable surfing the web, they are on edge while using acquisition 
enterprise applications. Hence, they default back to paper. 

Table 1 illustrates the relationship between Paper-Based, Paperless and Web- 
Based processes and mentalities, or the way people physiologically interact with the 
contracting environment. 
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-BASED PROCESS 

• Paper, Pen, Typewriter, Photocopy, Facsimile 

• Document Forms, Templates 

• Data is manually manipulated 

• Thinking one must manually handle paper during the process 

• Visualization of the paper 

• Data availability is ad hoc 

• Electronic Database, Application Software, Computers, Networks 

• Input forms. Reports, Queries 

• Data is manipulated by application software 

• Cerebral method used to spatially process information 

• Knowledge of applications and databases 

• Data is entered and requested by applications 

• A Paperless Process with a Paper-Based Mentality 

• Visualization of a Webpage 

• Data is manipulated by application software 

• Computers are similar 

• Web-Based interfaces are similar 

• Data availability is ad hoc 


Table 1. Web-Based Mentality 

A Paper-Based system is comprised of printed and hand written documents. 
These documents are organized and assembled into folders. While not being used, they 
are stored in filing cabinets provided space is available. The author has observed 
contracting personnel printing entire electronically stored contract folders for the desire 
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of working with paper. When asked about working with paper as opposed to keeping and 
working with files in electronic format, they cited it was more convenient to use paper 
documents when discussing contracting issues with colleagues. Other departments 
outside of contracting require paper documents and folders. Program managers and the 
legal department want full paper-based documentation in folders with wet-signatures. 

Electronically stored documents are not sufficiently protected in the author’s 
experience. Many electronically stored documents reside on personal computer hard 
drives under desks. A hardware failure can render the data, stored on the drive, 
irretrievable. All electronically stored data can be accidently deleted and lost. 

The Paperless environment consists of databases and applications residing on a 
networked enterprise system. Some of the procurement process has been automated as 
stated elsewhere in this report. It is possible to have a fully secure electronic system. 
Through the use of Redundant Array of Independent Disks and Uninterruptable Power 
Supplies, the chance of data loss is remote. Data server rooms can be locked down and 
fireproofed. Data can be encrypted and networks made secure. On the other hand, a 
paper document must be kept under lock and key due to being easily read and misplaced. 
In the author’s experience, interaction with present procurement applications is strained. 
An unintentional mouse click can have disastrous results. Proprietary or classified 
information may be sent to the wrong email address. When mailing with paper, outside 
mail goes into Priority or Express envelopes, down to the mailroom for stamping and out 
for delivery. Internal documents are sent in special envelopes for internal delivery. With 
email, there can be Reply or Reply to All combined with a concatenation of previous 
messages. In the author’s experience, he has received many emails that had unintended 
recipients. 

Web-Based, as defined by the author, is a convergence of present, automated, 
paperless, enterprise systems with the psychological feel and safeguards of a paper-based 
system. The web-based system consists of the present applications and databases that 
employ middleware for interoperable transparency. Data validation patches and metadata 
would be applied to existing software to insure data compatibility between applications. 
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In the author’s opinion, Web-Based applications are the paper of the future. 

To accomplish this, the DoD must implement a Web-Based User Interface (UI) 
that will replace the psychological and legal need for paper. Applications must link 
seamlessly and securely to facilitate movement within several enterprise systems. 

The individual’s User Interface would be stored on a Personnel Server and 
accessed with the Common Access Card (CAC) at logon. Single logon to other systems 
could be achieved by the application accepting the CAC logon. Systems that are not 
native to DoD would be accessed by retrieving the user identification and password for 
that particular application. A user identification and password record would be stored 
with the user’s profile information for each non-native application. The Virtual Desktop 
would be accessible through any web browser provided security conditions have been 
met. 

Applications and databases would reside on secured servers. Applications would 
be requested from the server when needed. When available, application updates would 
occur based on usage. Applications could be run on thin client computers entirely online 
with the user supplying data input. Other computers could have application updates 
pushed at the convenience of the IT department. This type of division allows many users 
to have access to a limited number of application licenses. 

Databases would transmit encrypted data to the users Desktop to be decrypted by 
the user’s CAC card. To insure security when logging off, data files on the user’s 
computer would be deleted and overwritten. 

To discourage the use of paper, the Virtual Desktop must be more user friendly, 
secure, and easily accessible. Utilizing the Virtual Desktop will enable procurement 
personnel to access their desktop from any desktop computer, notebook computer, or 
mobile Blackberry device as long as the security parameters are met. 

The screen layout or visual display would be organized to create a logical order to 
the flow of work. This could be done by using movable objects within various 
applications to customize the application’s look, feel, and use according to each user’s 
personal design. Several customized personal desktops could be stored for suit particular 
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contracting needs. This would be similar to spreading out and organizing one’s work on 
their desk. For instance, there could be a specific desktop for reviewing and signing an 
award from a Blackberry. 

C. WEB-BASED OVERARCHING ARCHITECTURE 

Service Oriented Architecture (SOA) and Web Oriented Architecture (WOA) are 
two solutions to the same problem. Until recently, SOA was thought of as the more 
robust of the two. With its reusable code, it is able to perform more complex and secure 
operations. Contrasted to WOA, which is resource oriented, has been thought, until 
recently, to be more limited and data focused. SOA is a system level architecture 
whereas WOA is interface-level. 

The technical aspects of the architecture are beyond the scope of this paper. An 
important difference between the two is WOA is less expensive to implement. SOAs 
have been tried but the return on investment has not been sufficient. However, WO As 
are thought of as a startup company resource. Recently IBM and Amazon have been 
testing this architecture because it is less expensive to develop. In addition, MindTouch 
is working with the Army developing and open source wiki collaboration and content 
management platform with IT governance (Smith, 2008). 

Combining present enterprise systems and their SOA style architecture with the 
WOA model would allow for the development of a truly paperless web-based system 
where personnel using the system would feel comfortable sharing information without 
the need for printing it out. The WOA is a cost effective solution for achieving a truly 
‘paperless’ solution for contracting. (Hinchcliffe, 2008). 

• WO As tend to have a very large and open-ended number of endpoints; one 
for each individual resource. Not an endpoint for each type of resource, 
but a URTidentified endpoint for each and every resource instance 

• WOA finds HTTP and related transfer mechanisms to be the ideal layer of 
abstraction for most applications 

• was emerged form the bottom up from the Web naturally and has the best 
support in simple procedural code and an XML parser 

• WOA tends to just use HTTPS 
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• WOA largely ignores the issue and lets Web services naturally represent 
whatever formats are desired 

• WOA is extremely easy to consume just about anywhere 

• WOA are easier to implement, scale better, and result in much greater 
uptake and usage scenarios (Hinchcliffe, 2008) 


Different Thinking: 
REST/WOA Puts the Focus on 
Web Resources Not Services 
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Figure 9. Web Oriented Architecture (From: Hinchcliffe, 2008) 


In the author’s opinion, Web-based architecture must be implemented by the DoD 
and Army to facilitate bringing web-based applications and databases to fruition. From 
the article ‘Oracle Fusion Architecture Eases the Adoption of Service-Oriented 
Architecture’, Summit Strategies the company suggests: 


During the past few years, a confluence of IT customers’ pressing 
technical and business requirements and the availability of new technical 
capabilities has set the stage for the next generation of business 
computing. Summit Strategies labels this generation as one of “dynamic 
computing,” and broadly characterizes it as an era in which IT resources 
become more automated, more agile and—most important—more 
synchronized with the business processes and objectives that the resources 
support. Dynamic computing and the business agility it promises, in turn, 
depends on various building-block tools and technologies. 
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None of these enablers is more important or wide-reaching than that of 
service-oriented architecture (SOA) (Oracle Fusion Architecture Eases the 
Adoption of Service-Oriented Architecture, 2006). 

As discussed in the previous section, SOA is designed for the enterprise, large 
systems level. SOA have been around for a few years, were expensive to implement and 
at the time unnecessary since corporate, business software was not run on the web. Now 
that open source and interoperability are necessary to reduce the cost of future software 
development, both SOA and WOA have been receiving a lot of interest from developers. 

OnLine Transaction Processing (OLTP) from Trigon Blue is an application using 
Server Side Scripting Server Side Scripting (such as Active Server Pages), it is possible 
to connect to other components of a distributed system in the form of business objects on 
the Transaction Server and to send messages to the Database Server (Web Based 
Architecture, 2008). 
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Figure 10. OnLine Transaction Processing (OLTP) (From: Web Based Architecture, 

2008) 
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D. SUMMARY 


Completing the system means taking the automated, paperless, proeurement 
enterprise system and eausing it to funetion as intended: paperless. To answer the 
question, “Why are aequisition people using so much paper?” the author compared 
processes and coined ‘mentality’ as a term referring to how people think and act. For 
example (to his frustration), the author has experienced being told to print entire folders 
for legal review and for use in negotiations. 

Web applications serve as the twenty first century paper. Web architecture will 
allow web-based applications and databases to exchange information securely without 
corruption. 
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VI. CONCLUSION AND RECOMMENDATIONS 


A. CONCLUSION 

The author’s research began with paper-based acquisition for the DoD. Next, he 
followed it to mainframe computers. This was followed by networks and personal 
desktop computers. Applications evolved from paper-based forms to electronic forms. 
Business practices have gone from written rules to rules that are embedded in the 
applications. 

As the present workforce retires, the incoming personnel must be prepared to 
carry on. People have become World Wide Web savvy. They read the news and do their 
banking online while seamlessly traversing web applications and databases of all types. 
This has been made possible due to the guidance of the World Wide Web Consortium. 

The DoD is improving its automatic procurement software daily. However, 
improving the software is not enough. The user interface lacks paper-based mentality. It 
does not feel right to the user. In the author’s opinion, that explains why SEWP decided 
on the fax form to initiate an order. The DoD needs to put a web-face on all applications. 

Web architecture and middle ware, applications are needed for the next step in 
efficient contracting. Going the web presents security issues. Data transmission can be 
made secure either though network security hardware or dada encryption applications. 

The pitfalls of the present system is the feeling that the task has been 
accomplished when in actuality the system is broken. It is difficult to fix a problem when 
you cannot see it. The IT people do not see the problem and the contracting people that 
see it do not know how to fix it. To compensate, they print and shred documents with 
regularity. 

B. RECOMMENDATIONS 

The DoD must transition from handling paper to utilizing web based virtual 
desktops to manipulate web applications. To accomplish this, they must eliminate the 
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psychological and functional need for paper. A notebook computer is the same size and 
weight as a folder and like a folder can be easily carried. In addition, paper is difficult to 
secure. Instead of photocopying and carrying paper, store data on a data server or USB 
that is encrypted with a polymorphic key tied to CAC card. 

Rather than logging into a specific personal computer with individual security, 
profiles should be stored on the profile server. Security enhancements could include the 
CAC card, biometrics and passwords. Access to the system would be through any device 
that supports online web applications and meets the security requirements for the 
information to be handled. For instance, one could logon to an Army server and gain 
information about the base but be restricted from contracting applications because his 
virtual desktop lacked a CAC card reader. 

Virtual desktops abound in college and corporate settings. Numerous computing 
devices and operating systems have the means for linking into online web applications. 
Besides the personal computer, mainframes, cell phones, personal digital assistants 
(PDA), televisions and video games can provide an interface. 

Build toward and online web based infrastructure. Using the SAP model of a 
large, integrated enterprise system, continue to improve on present applications, such as 
LMP, while building toward interoperability for the future. SAP’s Net Weaver 
implementation and standardized W3C databases will enable transparency in web-based 
transactions. 

Continue using the Oracle model of a standardized database tied to many different 
applications through the use of Oracle Fusion Middleware (OFM) and like products. 
Piecemealing applications into an enterprise system allows the DoD to fund the ‘best in 
class.’ In addition, it allows for one-off and rapid development applications. 

Build Service Oriented Architecture (SOA) for a large scale, reusable service that 
fulfills a distinct business function and Web Oriented Architecture (WOA) limited data 
focused functions (Smith, 2008). 

Dashboard applications like ACART will enable queries of multiple systems 
across the web. 
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C. SUGGESTED AREAS FOR FURTHER RESEARCH 

This thesis has made claims about the persistence of what has been called a 
‘paper-based mentality’ in systems that were intended to be ‘paperless.’ Future research 
needs to be done to examine the prevalence of this ‘paper-based mentality’ in contracting 
systems, and perhaps across the DoD. The author has indicated that the ‘paper-based 
mentality’ is persistent because paper has a human utility that is not captured in current 
systems. Future research needs to be done to better define and quantify that utility. 
Finally, the author has defined a construct called a ‘web-based mentality’ and claimed 
that it can capture the human utility of paper-based systems as well as the potential cost 
savings of paperless systems. Future research needs to be done to support this claim as 
well. 

Beyond the immediate claims of this thesis around WOA and the ‘web-based 
mentality’, research should continue to investigate the application of other leading edge 
information technology to Contracting. Further research should include best in class 
applications, transparent databases with appropriate metadata allowing information to be 
passed among applications without corruption or being misrepresented. 

As in organizational behavior, explore the environment looking at people, 
surroundings and their work to be accomplished. Look at the employees’ ‘tools of the 
trade.’ Should the employee be made to adapt or should designers build to reduce the 
learning curve by building to fit the person. The way people think, act, and move must 
be the design criteria when designing for the future. Human behavior and utility 
investigations should be performed to find the most efficient, cost effective method of 
contracting. 
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APPENDIX A. 


Defense Automatic Addressing System Center (DAASC) (DAASC, 2008) 
https://www.daas.dla.mil/daashome/daasc_services.asp 

The DAASC INQuiry System provides information on Communication Routing 
Identifiers (COMMRI), DoD Activity Address Codes (DODAAC), Routing Identifier 
Codes (RIC), Military Assistance Program Address Codes (MAPAC) and National Item 
Identification Number (NUN) Codes. 

Additionally, eDAASINQ, an enhanced version of DAASINQ described above, 
provides additional queries and downloads by service or “All” in “TAl” delimited 
format. eDAASINQ is PKI-enabled and access to the application may be requested by 
submitting a System Access Request (SAR). 

DAMES is a PC based software package that provides the user with the capability 
to communicate with the Defense Automatic Addressing System Center (DAASC). It 
provides capability to send/receive logistics transactions and narrative text through a 
modem using standard telephone lines or the Internet. 

The LMARS/CWT Reporting System is a capability to nodally track material as it 
flows through the logistics pipeline and report the associated response times. The office 
of the Under Secretary of Defense for Logistics has identified twelve nodes for 
measuring the logistics pipeline. 

DAASC Logistics Reports, including Priority Designators, LIDS, MILSBILLS, 
MILSTEP and Publications. 

MILSBILLS Inquiry System is a query system providing both local and remote 
users the capability to query and display Interfund Bills (MILSBILLS) and Materiel 
Obligation Validation (MOV) files and generate retransmit requests on-line. The MOV 
System contains all inquiry batches and AE status documents submitted during the recent 
quarter, retaining the data for 90 days. 
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WEBLINK and PCLINK have transitioned to Asset Visibility. 
https://www.av.dla.mil/welcome/welcome.jsp 

Transportation Account Code Inquiry - TACs are used and assigned daily all over 
the world by shippers, Transportation Offices, Ports, and Transportation Component 
Commands (TCCs), and are essential to the operation of the DTS. DAASC maintains a 
single repository for updating TAC codes and the dissemination of daily changes. Also 
provided are various data base queries, TAC manual publication generation and service 
downloads. 

The DSS WEB BRIDGE provides a web-based, read-only, capability for 
customers to track logistics transactions exchanged between the DEA Distribution 
Standard System (DSS) and the Navy Eleet Industrial Supply Center (EISC) wholesale 
supply system (UADPS U2). The DSS Bridge translates transactions to/from the Defense 
Eogistics Standard System (DESS) format processed in DSS and the Navy User Defined 
Eile (UDE) format processed in the Navy wholesale supply system. The DSS 
WEBBRIDGE provides images of the transactions and the associated communications 
information as they flow through the DSS Bridge application. 

Web Requisitioning (WEBREQ) is a DAASC Web product that provides 
customers a means to input materiel requisitions, cancellations, follow-ups, 
modifications, and Materiel Obligation Validation (MOV) documents. WEBREQ can 
also provide status documents back to the user. 

Web Supply Discrepancy Reporting (WEBSDR) system will provide a web-based 
entry method for SDRs, routing for web submissions and logistics transactions according 
to business rules, any-to-any translation to support unique and standard transaction 
formats, information exchange between the action office and the shipper, SDR resolution 
responses, capture of SDR and response management statistics and assimilation of SDR 
metrics along with Customer Wait Time/Eogistics Response Time in support of perfect 
order fulfillment. This process reduces manual SDR form creation and provides an 
automated process for tracking SDR response information. 
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WEB Visual Logistics Information and Processing System. WEB VLIPS is a web 
based, access controlled query system that is useable from any Internet attached PC. It 
accesses the Logistics On-line Tracking System (LOTS), a DAASC relational database 
system, which portrays the life cycle of a logistics action. 
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APPENDIX B 


The Army Single Face to Industry (ASFI) (ASFI, 2006) 
Users Guide, August 2006 
3.0 ASFI EDIT CRITERIA 


Regardless of the process utilized to post solicitation data/documents certain data 
must be present and valid. In order to successfully post solicitation data/documents to the 


ASFI 


Data Item 

Expected Results 

Solicitation Number (Mandatory) 

Maximum Eength =13 characters 

Amendment Number (Mandatory) 

Maximum Eength = 4 characters 

Close (Response) Date (Mandatory) 

Eormat = DDMMYYY (Must be greater 
than current date) 

NAICS 

If provided, must be valid NAICS 

Solicitation URL (Mandatory) 

Maximum Eength = 250 characters 

Solicitation Issue Date 

Eormat = DDMMYYYY 

Solicitation Status (Mandatory) 

Values; 00 = Initial or Original Solicitation 

01 = Cancellation (Amendment) 

02 = Add (Amendment) 

04 = Change 

05 = Replace (Conformed Solicitation) 

17 = Cancel, to be Reissued 

Buyer Name (Mandatory) 

Maximum Eength = 35 characters 

Buyer E-mail Address (Mandatory) 

Maximum Eength = 80 characters 

Buyer Phone Number (Mandatory) 

Maximum Eength = 30 characters 

ESC 

If provided, must be valid ESC 

Noun 

Maximum Eength = 65 characters 
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APPENDIX C 


Wholesale Logistics Modernization Program 


The business processes used for the work¬ 
ing capital fluid have not changed signifi¬ 
cantly m the last tluee decades. As a result, 
logistics processes have become outdated 
and costly to mamtain. The Wdiolesale 
Logistics Modeiiiization Program was thus 
devised to miprove the agility, reliability, 
and responsiveness of the AWCF activities. 
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Tluougli adoption of private sector supply chain and financial 
management best practices, WLMP will improve force readiness 
and mission perfomiance, take advantage of efficiencies in sys¬ 
tems operations, improve system maintainability and adaptability, 
and provide full asset visibility tlnough the mtegration of logistics 
and financial data, giving the AWCF an integrated cost accountmg 
system. Tluougli the DFAS Corporate hifonnatiori Infiastnictirre 
(DCII) eri\ uormierit. WTLMP additionally will mterface with DoD- 
wide USSGL data to uiiprove accoimtmg and finance reporling for 
AMC at the AMC, Army, and DoD levels of mterest. Tliis is just 
one illustration of how the Army is progr essmg toward the use of 
transaction-driven. USSGL-based accountmg systems. 

Wlien fiilly implemented. WTMP will provide a single pomt of 
entry for the recordmg. reportmg. and analysis of mventory and 
related financial data, dhectly addressmg an identified mteriial 
control weakness cited m the Army's FY 2000 financial state¬ 
ments. The modeniization progr am will provide a financial uifor- 
niation management system while smiultaneously providmg the 
logistics cormnimity with easy access to online, real-tune mforma- 
tion at a detail le\ el low enough to enable data to be sununarized 
and sorted. Managers will be able to irse these data to perform 
such ftmctions as Activity-Based Costmg and bringmg financial 
data for the AWCF luider general ledger control. 
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APPENDIX D 


DoD Architecture Framework (DODAF) (DODAF, 2007) 

Version 1.5, Page 2-13 

CONCEPT: Populate the Net-Centric Environment 

This concept addresses the data, information, and capabilities that are being made 
discoverable and accessible on the NCE so that they can be leveraged by others. The 
information and capabilities provided to the NCE should support discovery and enable 
access to authorized users (human or machine, known and unanticipated) using a 
webbased device or platform. While there are many methods and technologies to provide 
information to the NCE, web-based, open technology standards are preferred. As 
information and capabilities are provided to the NCE, architects and engineers should 
ensure that they are done so in a manner that provides the most value, in convenient 
ways, to the broadest set of potential users. In essence, architects and engineers should 
provide value-added services to the NCE. 

The term service has many definitions, depending on the context and intended 
use. DoDAE vl.5 embraces the IEEE 1003.0 definition of a service, which is “a distinct 
part of the functionality that is provided by a system on one side of an interface to a 
system on the other side of an interface.” To better align with overarching DoD net- 
centric strategies, the DoDAE vl.5 extends this definition of service to include those 
interfaces that allow execution of a business or mission process, or exchange information 
among both machine and human users via standard interfaces and specifications without 
regard for the underlying implementation. Eor example, a service can be an information 
processing routine that is invoked to assist in a business processing function (e.g., payroll 
lookup). Or, a service can be one that provides map imagery directly to a human that has 
access to a web-based device or platform (e.g., a web-enabled PDA). Accordingly, web 
portals, web sites, and Web Services all fall within the definition of a ‘service’ as 
discussed in DoDAE vl.5. Note, while the net-centric guidance provided in the DoDAE 
vl.5 focuses on webbased services, much of the guidance is applicable to any form of 

electronic information processing or access service. Regardless of the type of service that 
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provides information and/or a capability to the NCE, the service provider (i.e., the entity 
that actually provides the capability) will need to describe the service in a robust manner 
that gives both humans and machines enough details to make a decision on when, where, 
and how to use the service (in addition to other important details such as performance 
level expectations and information assurance specifics). A service specification is the set 
of descriptive metadata that provides a consistent way to describe the use, composition, 
and implementation of a service to service providers, users, developers, and managers. A 
service specification should be provided for each service that is or will be provided to the 
NCE. The service specification enables services to be documented in a consistent 
manner, and the DoD-wide Service Specification 

Template (SST) should be used to the extent possible for describing each service. 

Regardless of the precise service specification template employed in the subject 
architecture, a minimum set of information for each service must be provided in the 
following categories: 

• Interface Model Category - describes the interface, available operations, 
any faults that an individual operation may generate, and points to access 
the service 

• Information Model Category - describes the capability the service 
provides, the expected input and output data model, and outlines the 
available metadata for the service 

• Behavior Model Category - Identifies how the service interacts with other 
services, describes the underlying processing rules of the service, and 
describes the multiple integration patterns available to users of the service 

• Eault Model Category - describes how the service will handle faults and 
under what conditions a fault may be returned to the consumer 

• Quality Model Category - describes the security requirements of the 
service, the QoS levels, and any performance considerations for service 
deployment 

• Point of Contact Information Category - describes the types of contacts 
associated with a service, which may include developers, managers, or 
maintenance organizations. 

• Service Access Point Information Category - describes the message 
format and transmission protocol. Uniform Resource Eocator (URE), the 
operational status and point of contact, and the lifecycle step of the service 
(e.g.. Development, Testing, or Production) 
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The level of detail contained within a service specification is driven partly by the 
type of service. Human-facing web services (e.g., portals, web sites) generally need only 
be specified in a manner that allows a human to find and understand what the service 
does, how to access it, and how to understand its outputs. Both human facing services and 
system facing services are described using the template. However, where the primary 
user of services is another system, a more detailed specification is required to be machine 
interpretable. These system consumable services generally will be specified through the 
service information, service interface, and service implementation categories in the 
specification template. 
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APPENDIX E 




www.sewp.iiaM.gov 


Contract Holders - 


SEWP Tools > 
Customer Service > 


i 


Helpline: (301) 286-1478 
help@sewp.nasa.gov 

Orders: FAX (301) 286-0317 
sewporders@sewp.nasa.gov 


SEWP Fax Form Tool 


Note: Items marked with are mandatory! 


Agency Specific > 


Fast Access 


FAQ 


Training Video 


Procurement Resources 


Manufacturer Lookup 


Request for Quote 


Event Calendar 


Address and Directions 


Give Us Your Feedback 


* Pages including Cover: 


I” Notify me when this order has been processed in the the SEWP office and sent to the Vendor. 


Anticipated Delivery Date: 


I Government Contracting Agency: | Zip Code: | 

If you used the NASA SEWP RFQ Tool, please list the RFQ sequence | 

508 Compliance (optional) 

Is this acquisition compliant with Section 508 of the Rehabilitation Act of 1978, 1998 Ammendments? 


508 is not applicable/exempt 


Yes Compliant 


Not Compliant 


To view the full text of the accessibiirty standards, go to http://wvfw.access-board.gcv/S08.htm 
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